Implements import count tracking across all import operations to enable
accurate analytics event tracking in PostHog.

Changes:

Import Classes (8 files):
- Added public $imported counter property to track successfully imported rows
- Incremented counter for each processed row in collection() method
- Files: ContactImport, DriverImport, FleetImport, FuelReportImport,
  IssueImport, PlaceImport, VehicleImport, VendorImport

Controllers (8 files):
- Added $importedCount variable to accumulate counts across multiple files
- Instantiate import class to access the counter
- Return 'imported' field in JSON response with total count
- Files: ContactController, DriverController, FleetController,
  FuelReportController, IssueController, PlaceController,
  VehicleController, VendorController

Response Format:
{
  "status": "ok",
  "message": "Import completed",
  "imported": 47
}

Benefits:
- Frontend can now track exact import counts in PostHog analytics
- Better UX - users see how many records were imported
- Consistent with existing patterns (OrderController.importFromFiles)
- Enables accurate resource.imported event tracking

Related:
- Complements ember-core events service implementation
- Supports PostHog analytics integration in internals

feat: Add resource count tracking to import responses

…rt schema

- Remove 'meta' from excludeColumns to make it available in report builder
- Add meta column definition with JSON type for custom fields and metadata
- Add Transaction relationship with auto-join support for financial reporting
- Include nested TransactionItems relationship for line-item details
- Add computed columns for transaction amount aggregates (sum, avg, count)

This enables users to query and report on:
- Order metadata and custom fields
- Transaction financial data (amount, currency, gateway, status)
- Transaction line items (details, codes, amounts)
- Financial aggregates across orders

Resolves the limitation where users could not report on critical financial
data and custom metadata associated with orders.

…on-to-report-schema

feat: expose meta column and transaction relationships in Orders report schema

When a user_uuid is provided during driver creation, check whether a
driver profile already exists for that user within the current company
before proceeding. If one is found, return a 400 error response with
the message 'This user account already belongs to a driver.' rather
than silently creating a duplicate record.

The existing path that handles email/phone-based lookups already had
this guard in place; this change closes the equivalent gap in the
user_uuid-based creation path.

…cate driver check

The previous fix returned response()->error() directly from inside the
createRecordFromRequest onBefore callback. The trait checks for a
JsonResponse return and short-circuits correctly, but the outer
createRecord method then passed the JsonResponse object as $record
into the Driver resource serializer (line 245), causing:

  ErrorException: Undefined property: Illuminate\Http\JsonResponse::$id
  in DelegatesToResource.php

The correct approach is to throw a \Exception from within the callback,
which propagates out of createRecordFromRequest and is caught by the
existing catch (\Exception $e) block, which then returns
response()->error($e->getMessage()) — producing the correct 400 JSON
error response to the frontend.